ci: pull upstream ecosystem-ref fixes (bokeh, jrnl-org) + fork-side Windows libclang exclude - #99

Summary

Follow-up to the two non-required CI failures flagged (and left unfixed) while landing PRs #94/#96/#97/#98: the ecosystem job's project errors and the cargo test (windows-latest) crash. Investigated both against astral-sh/ruff upstream before touching anything, per this repo's own "measure before claiming a fix exists" discipline.

1. Two real upstream cherry-picks (clean, no conflicts)

The ecosystem job reported 5 project errors. Two of them are stale branch refs this repo inherited at fork time and upstream has since fixed:

• 67ffd19e — ruff-ecosystem: bump bokeh/bokeh branch to branch-3.10 (#26987) (was branch-3.3, deleted upstream)
• bd75eb1c — Update branch for jrnl (#27007) (was develop, renamed to main)

Confirmed via the exact CI log text on this fork (job 95614539452, PR run 32105673308):

Failed to clone bokeh/bokeh: fatal: Remote branch branch-3.3 not found in upstream origin
Failed to clone jrnl-org/jrnl: fatal: Remote branch develop not found in upstream origin

Cherry-picked verbatim (git cherry-pick), touching only python/ruff-ecosystem/ruff_ecosystem/defaults.py and scripts/check_ecosystem.py — no other files, no unrelated upstream drift pulled in.

The other 3 of the 5 ecosystem errors are NOT upstream-fixable and are intentionally left alone:

• rotki/rotki and indico/indico reference RUF105 in their own config, a rule that does not exist in this fork at all (git grep confirms zero hits; it exists upstream in noqa_comments.rs). Porting it is a real new-rule addition, not a ref bump.
• python-trio/trio references the selector builtin-argument-shadowing (the human-readable rule name, not its code A002). Upstream resolves that via a preview-gated "human-readable rule names" feature (is_human_readable_names_enabled, Rule::from_name, UnresolvedRuleSelector::resolve) that is entirely absent from this fork (git grep = zero hits).

Both are legitimate feature ports, not cherry-picks, and out of scope here — noted so they aren't silently dropped.

2. Fork-side fix: exclude ruff_cpp_spo from --all-features on Windows

This is NOT an upstream cherry-pick — ruff_cpp_spo is a fork-only crate (C++ SPO/transcode harvest arm) that doesn't exist upstream, so there is no upstream commit addressing it.

cargo-test-other's cargo nextest run --all-features --profile ci turns on ruff_cpp_spo's libclang feature on windows-latest too. The clang crate dlopens libclang at runtime there, and every libclang-backed test aborts with 0xc0000005 (Invalid access to memory location) instead of failing cleanly — confirmed via job 95617262943 on run 32106599591 (6 ABORTs, all under ruff_cpp_spo::clang_walker::* / libclang_tests::*). macos-latest runs the identical tests successfully.

Excludes ruff_cpp_spo from both the nextest run and the doctest run, Windows-only, rather than dropping --all-features workspace-wide or touching macOS.

Test plan

• git diff confirms only the two intended lines changed in the ecosystem-ref cherry-picks
• python3 -c "import yaml; yaml.safe_load(...)" — CI workflow YAML parses
• uvx prek run --from-ref origin/main --to-ref HEAD — all hooks pass except zizmor, which fails identically against the unmodified upstream origin/main copy of ci.yaml in this sandbox (403 from github.com/ghapi/advisories, no outbound GitHub API access here) — confirmed environmental, not caused by this diff
• CI on this PR (the actual falsifier — real GitHub Actions gets real libclang/network access this sandbox doesn't)

Kept as a separate branch, not merged into the drill-loop work landed in #94/#96/#97/#98.

Generated by Claude Code